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Cross-Reference to Related Applications 

The current application is related to co-pending and commonly assigned 
U.S. Application No. 10/650,211 entitled "Secure Intranet Access," filed on August 
8, 2003, which is a continuation of U.S. Patent No. 6,640,302 . Patent No. 6,640,302 
10 is also a divisional of issued U.S. Patent No. 6,081,900 . The disclosures of these 
three matters are incorporated by reference herein and below. 

Field of the Invention 

The present invention relates to network security and in particular to 
15 techniques for managing secure communications. 

s 

Background of the Invention 

Increasingly, individuals are accessing resources over the World-Wide Web 
(WWW) using Internet browsers. In many instances, these communications are 

20 made in an insecure fashion using non-secure protocols, such as Hypertext Transfer 
Protocol (HTTP). In other instances, these communications are made in secure 
fashion using secure protocols, such as HTTP over Secure Sockets Layer (SSL) 
referred to as HTTPS. 

Secure access is often needed when the resources are subject to security 

25 access policies. For example, an enterprise's Intranet website which includes 
internal enterprise resources and information is normally only available to 
employees through secure Internet communications, such as HTTPS. The 
employees authenticate to the Intranet website and then remotely communicate with 
the resources of the Intranet via the Internet using HTTPS. 

30 During secure sessions with a secure site, an individual can use a browser to 

perform a variety of transactions. These transactions can reference links to internal 
or external information or can reference links to internal of external sites. External 



Attorney Docket No.: 1565.066US1 1 
Client Docket No.: IDR-672 



information or external sites may or may not be within the control or purview of the 
secure site. Thus, there is a potential that when a transaction attempts to access 
external information or an external site that the access attempt may create a security 
issue or security hole during the secure session. 
5 As a result, traditional Internet browsers are equipped with logic to detect 

these situations and to generically issue security warnings via browser interfaces. 
However, in many instances, these messages are not correct, that is, the information 
or site that is attempting to be accessed is often not a security problem. Moreover, 
in many instances, these messages are not particularly informative to the individuals 
10 as to the true security risk associated with the information or site that is attempting 
to be accessed. 

Thus, individuals experience numerous service interruptions during a secure 
session which requires them to manually inspect and disregard any unnecessary 
security warnings. Moreover, these security warnings are often too generic to 
15 provide individuals with any meaningful assessment as to the true security risk 
associated with access attempts to potentially insecure information or sites. 
Accordingly, these service interruptions affect an individual's overall efficiency and 
comprehension of information during the secure session and are not desired or 
useful. 

20 Therefore, there is a need for improved techniques for managing secure 

communications, such that unnecessary security warnings are suppressed and 
security threats are more meaningfully communicated. 

Summary of the Invention 

25 In various embodiments of the present invention, techniques for managing 

secure communications are described. An external client residing on an external 
site establishes a secure session with a secure site over a network. During that 
secure session, the external client makes a number of transactions; some of these 
transactions are associated with potentially insecure communications. These 
30 potentially insecure communications are inspected in advance of making them 

available to the external client and zero or more actions are performed based on that 
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inspection. 

More specifically, and in one embodiment of the invention, a method for 
managing secure communications is presented. A secure session is established on a 
secure site with an external client, which communicates from an insecure site. 
5 Access attempts are detected during the session which is directed to potentially 
insecure transactions. The access attempts are transparently managed by inspecting 
the access attempts before making them available to the external client. 

In another embodiment of the present invention, another method for 
managing secure communications is provided. Potentially insecure transactions 

10 occurring during a secure session are detected, the insecure transactions result from 
actions requested by an external client participating in the secure session. The 
potentially insecure transactions are inspected in advance of satisfying the actions 
requested and a determination is made for permitting the insecure transactions to 
proceed unmodified by performing the actions requested for the external client, 

15 permitting the insecure transactions to proceed in a modified fashion, or denying the 
insecure transactions by denying the actions requested. 

In still another embodiment of the present invention, a secure 
communications management system is described. The secure communications 
management system includes a secure communications manager and a proxy. The 

20 secure communications manager manages a secure session with an external client, 
which is associated with an insecure site. The proxy interacts with the secure 
communications manager in order to inspect potentially insecure communications 
requested by the external client during the secure session. Furthermore, the proxy 
selectively processes the potentially insecure communications on behalf of the 

25 external client within the secure session. 

In yet another embodiment of the present invention, a secure 
communications management system is presented. The secure communications 
management system includes a secure session, secure reference links, and 
potentially insecure reference links. The secure reference links are accessible within 

30 the secure session and the potentially insecure reference links are accessible from 
the secure session. An external client associated with an external site establishes the 
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secure session with a secure site. The external client references the secure reference 
links and the potentially insecure reference links during the secure session, and the 
potentially insecure reference links are inspected and modified in advance of being 
made available to the external client during the secure session. 
5 Still other aspects of the present invention will become apparent to those of 

ordinary skill in the art from the following description of various embodiments. As 
will be realized the invention is capable of other embodiments, all without departing 
from the present invention. Accordingly, the drawings and descriptions are 
illustrative in nature and not intended to be restrictive. 

10 

Brief Description of the Drawings 

FIG. 1 is a flowchart representing a method for managing secure 

communications; 

FIG. 2 is a flowchart representing another method for managing secure 

15 communications; 

FIG. 3 is a diagram of a secure communications management system; and 

FIG. 4 is a diagram of another secure communications management system. 

Detailed Description of the Invention 

20 In the following description, reference is made to the accompanying 

drawings that form a part hereof, and in which is shown by way of illustration 
specific embodiments in which the invention may be practiced. These embodiments 
are described in sufficient detail to enable one of ordinary skill in the art to practice 
the invention, and it is to be understood that other embodiments may be utilized and 

25 that structural, logical, optical, and electrical changes may be made without 

departing from the scope of the present invention. The following description is, 
therefore, not to be taken in a limited sense, and the scope of the present invention is 
defined by the appended claims. 

In various embodiments of the invention, a secure session is discussed. A 

30 secure session is a communication dialogue that occurs between an external client 
and a secure site over a network, such as the Internet. In one embodiment, the 
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secure communication is a HTTPS dialogue managed within an Internet browser 
that the external client uses for accessing the secure site. The communications 
occurring within the secure session on the secure site need not be secure {e.g., 
HTTP can be used), but communications between the external client and the secure 
5 site are secure (e.g., HTTPS). A technique for performing these translations 

between external clients associated with insecure sites and secure sites is described 
in U.S. Patent Numbers 6,640,302 and 6,081,900 both commonly assigned to 
Novell, Inc. of Provo, Utah, both entitled: "Secure Intranet Access." The 
disclosures of these patents are hereby incorporated by reference herein. 

10 An external client is a computing resource (e.g., device or application) or 

user that participates in the secure session. In one embodiment, the external client 
uses an Internet browser during the secure session to interact with the secure site 
and make access requests for information or services identified within the secure 
site. Some of the requested information or services are associated with potentially 

15 insecure transactions. Potentially insecure transactions are transactions that may or 
may not create a security hole or problem during the secure session. 

For example, a WWW browser page that resides within the domain of the 
secure site may include reference links to other sites or information that is not 
identified as being secure by their embedded reference links. Thus, a secure WWW 

20 browser page (e.g., referenced by HTTPS) can include embedded links to another 
insecure browser page or site (e.g., referenced by HTTP). Conventionally, such a 
scenario would result in a security warning message being displayed within the 
browser to the external client. However, as will be described below in greater 
detail, this security warning need not always be displayed, need not always be 

25 displayed in generic and conventional manners, and need not always result in an 
insecure transaction that occurs during the secure session. 

In one embodiment of this invention, the techniques presented herein for 
managing network traffic are implemented in the iChain® and Secure Excelerator 
products, distributed by Novell, Inc., of Provo, Utah. However, the teachings of the 

30 invention can be integrated and implemented in network protocols, proxies, network 
appliances, or any applications that are designed to manage secure communications 
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in the manners described herein and below. All such implementations are intended 
to fall within the scope of the invention. 

FIG. 1 illustrates a flowchart of one method 100 used for managing secure 
communications. The method can be implemented in one or more software 
5 applications residing on a secure site. The method's 100 processing is designed for 
managing securing communications between the secure site and an external client. 
The processing of the method 100 represents the actions taken by applications 
processing on the secure site. Furthermore, in some embodiments, the processing of 
the method 100 is partially implemented in a proxy that is accessible from the 
10 secure site. 

At 1 10, a secure session is established between an external client and a 
secure site. The secure session is established after the external client authenticates 
itself to the secure site. Moreover, in some embodiments, the secure session is 
carried out using HTTPS communications over the Internet using a WWW browser. 

15 During the secure session, the external client expects communications to be secure 
and the secure site expects its resources, information, and services to remain secure. 

After the secure session is established, the external client begins to make a 
number of transactions with the resources, information, or sites controlled by the 
secure site. At some point during the secure session, at least some of these 

20 transactions will be detected at 120 as access attempts that are directed to potentially 
insecure transactions. 

Potentially insecure transactions are references to resources, information, or 
sites that are not managed by secure communications (e.g., HTTPS). The 
transaction references are "potentially" insecure until a determination is made as to 

25 the true nature of these references. That is, references that are wholly contained and 
managed within the secure site may not be referenced internally (within the secure 
site) using secure communications (e.g., HTTPS) but these references are still 
secure since there is no way to access them outside the context of the secure site. 
These types of references are not actually insecure, although they appear to be 

30 insecure to the secure session, since they are not referenced by secure 

communications (e.g., HTTPS). Conventionally, these types of references would 
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trigger security warnings within the external client's WWW browser during the 
secure session, creating confusion and inconvenience for the external client. 

Other potentially insecure transactions can include references to sites that are 
known to, controlled by, or trusted by the secure site. Again, in these instances the 
5 references are not actually insecure once it is determined that the sites are acceptable 
to the secure site. Conventionally, any potentially insecure transaction would 
generate a security warning or in some cases prevent access to the suspect reference. 
Here, these references are not considered insecure once their relationship and 
identity are established within the secure session. 

10 Other types of potentially insecure references cannot be known to be unsafe 

or insecure until they are actually accessed. However, it is not desirable to permit 
the external client to directly access these references, since if a potentially insecure 
reference turns out to be actually insecure, the secure session will already be 
compromised as soon as the external client access there offending references. These 

1 5 types of insecure references will be processed and handled by a proxy acting on 
behalf of the external client in the manners discussed below. 

Correspondingly, at 130, the access attempts that are associated with 
potentially insecure references are transparently managed and inspected by the 
processing of the method 100 in order to determine what action should be taken on 

20 them, if any. One technique that can be used for inspecting the access attempts is to 
pre-acquire the information associated with the requested access attempts in cache 
or storage and scan the contents or metadata associated with the information, as 
depicted at 140. 

During the inspection, the contents or metadata of the information that is 
25 desired by the external client's access attempt may identify embedded reference 
links to an external site not directly controlled by the secure site at 142 or may 
identify embedded reference links to other information wholly contained within or 
under the control of the secure site at 144. Moreover, the embedded reference links 
may be associated with secure or non-secure communications. This information is 
30 also part of the embedded reference links. 
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Next, at 150, based on the inspection, the processing of the method 100 takes 
zero or more actions against the pre-acquired information before making the pre- 
acquired information available to the external client in order to satisfy the access 
attempt made by the external client. 
5 If the access attempt is associated with an external site that is not known to 

or trusted by the secure site, then, at 152, a proxy can be used to process the external 
client to the external site and process any additional actions performed by the 
external client at that external site, within the secure session. One technique for 
doing this is using the secure intranet techniques described in U.S. Patent Numbers 

10 6,640,302 and 6,081,900 both commonly assigned to Novell, Inc. of Provo, Utah. 
The disclosures of these patents are hereby incorporated by reference herein. These 
secure intranet techniques process insecure communications within a secure site 
(Intranet) on behalf of an external client and make them appear secure to the 
external client by translating HTTP requests to HTTPS requests and vice versa. 

15 If the access attempt is associated with references to non-secure information 

that is wholly contained and available within the secure site, then at 154, the 
processing of the method 100 translates all non-secure references to secure 
references and makes the references available to the external client during the secure 
session. By performing this translation the external client's browser will not detect 

20 any potentially insecure references when it renders the information to the external 
client and as a result, the translation will effectively suppress normally occurring 
warning messages from being presented to the external client during the secure 
session at 156. This is a more accurate reflection of the true nature of the 
information requested by the external client, since that information is only available 

25 within the secure site during a secure session. Thus, with the teachings of this 
invention the external client is not bombarded with security warnings when such 
warnings are not accurate and not needed. This makes for a more meaningful user 
experience during the secure session and promotes better external client 
comprehension during the secure session. 

30 In fact, a variety of actions can be performed at 140 once the potentially 

insecure references are inspected. For example, it may be determined that the 
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insecure references are in fact potentially harmful and thus no action at all is 
performed. This will result in the external client's normal security warnings to be 
issued from within the browser with respect to the insecure references. In other 
embodiments, the potentially insecure reference can be deemed harmful based on a 
5 number of factors, such as a cookie being present which was added to the reference 
header. In these situations, the insecure reference can be removed entirely from the 
information presented to the external client, such that the external client is not 
capable of ever actually viewing or accessing the insecure reference. In addition, 
the access attempt associated with the insecure reference can be logged or sent as a 

10 notification to another security entity. Moreover, the processing of the method 100 
can generate more specific and custom security messages for the external client that 
more accurately explains the security risk associated with the external client's 
attempt to access the insecure references. 

In still other embodiments, the processing of the method 100 may determine 

1 5 that the access attempts being made by the external client are associated with 
references that are in fact under the control of known or trusted sites. In these, 
situations the access attempts are permitted to proceed by translating the insecure 
communication references (e.g., HTTP) into secure communication references (e.g., 
HTTPS), such that communications appear to be secure to the external client during 

20 the secure session. This also serves to suppress any naturally occurring security 
warning messages that the external client's browser would issue upon detecting the 
insecure communication references during the secure session. 

The embodiments of FIG. 1 permit a more meaningful user experience and 
interaction during a secure session with a secure site. Secure communications are 

25 better managed with the embodiments of this invention. This is so, because 
conventionally a variety of non-useful and inaccurate security warnings often 
bombard a user during a secure session. However, the embodiments of this 
invention removes these unnecessary warnings and more closes manages and 
monitors the true nature of potentially insecure transactions that occur during the 

30 secure session, in order to take more intelligent action for and present better 
explained messages to the user. 
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FIG. 2 is a flowchart representing another method 200 for managing secure 
communications. The processing of the method 200 is implemented in a computer 
readable and accessible medium and is embodied on a secure site. The processing 
of the method 200 interacts with a secure session being managed on a secure site 
5 between the secure site and an external client. The external client resides on an 
insecure site and accesses the secure site using secure communications over a 
network. 

An external client establishes a secure session with a secure site. During that 
session, the client attempts to perform potentially insecure transactions at 210. An 

10 insecure transaction is potentially insecure if that transaction includes references to 
a resource, information, or a site using an insecure communication protocol or 
includes references to a resource, information or a site not known or under the 
control of the secure site. 

One technique for determining if information includes potentially insecure 

1 5 transactions is to pre-acquire a WWW browser page requested by the external client 
and scan its contents for embedded reference links directed towards non-secure 
communications (e.g., HTTP) or directed towards links associated with resources, 
information, or sites not known to the secure site (this can be achieved by a lookup 
in a directory, data store, file, etc.). 

20 If an external client's access attempt is determined to include potentially 

insecure references, then each of these potentially insecure references is more 
thoroughly inspected at 220. Inspection at 220 will determine if a potentially 
insecure reference is a secure reference, a low risk reference, or a true insecure 
reference. An example of a potentially insecure reference that turns out to be a 

25 secure reference, is a non secure reference (e.g., HTTP) to information that is 

wholly contained and accessed within the secure site (e.g., a file or program that is 
only accessed from within the secure site). A potentially insecure reference is a low 
risk reference when that reference is to an external site that is trusted by the secure 
site. A potentially insecure reference is a true insecure reference when the 

30 processing of the method 200 determines the content or metadata of the reference 
has been tampered with or is associated with a known insecure reference. 
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Based on the inspection, at 230, a determination is made to take zero or more 
actions on the content of the potentially insecure reference in advance of making 
that potentially insecure reference available to the external client in order to satisfy 
the external client's original access attempt for information which includes that 
5 potentially insecure reference. At 240, the determination can be based on whether 
the access attempt is associated with content that references information or 
resources available within the secure site or whether the access attempt is associated 
with content that references an insecure site. 

If the access attempt is directed to information that is known to be insecure, 

10 then at 241, the access attempt can be denied and the external client will not be 
permitted to make any such attempt during the secure session. Moreover, in some 
embodiments, any such access attempt can be logged for subsequent reporting or 
dynamically sent to appropriate or interested security entities. In fact, other final 
states associated with the access attempt that is denied can also be logged or 

15 reported. 

If the access attempt is directed to information that is considered low risk, 
then, at 242, no action is taken on the external client's access attempt at all. 
Consequently, the external client's browser will issue normally occurring security 
warning messages to the external client before the access attempt is permitted to 
20 proceed. 

If the access attempt is for information that is not within the processing 
control of the processing of the method 200, then, at 243, the transactions associated 
with the access attempt can be performed within a proxy on behalf of the external 
client. When these transactions are performed, the non-secure communications 

25 (e.g., HTTP) are translated to secure communications (e.g., HTTPS) between the 
sites associated with the access attempt and the external client. This occurs 
transparently, such that the external client is unaware that the translation is 
occurring and such that the external client's WWW browser does not issue any 
security warning messages to the external client. 

30 If the access attempt is for information that is within the processing control 

of the processing of the method 200, then, at 244, references made to the 
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information are converted into secure communications and then provided to the 
external client. In other words, references to HTTP embedded links are converted 
to references to HTTPS embedded links. This, at 245, suppresses normally 
occurring security warning messages that the external client's WWW browser 
5 would typically issue when non-secure (e.g., HTTP) references are detected in 
information that is being presented to the external client during a secure session 
(e.g., HTTPS session). 

In addition, in some embodiments, the processing of the method 200 may 
generate its own custom warning messages for the external client's access attempts 

1 0 and present these to the external client in place of what would normally be displayed 
by the external client's WWW browser. This permits the processing of the method 
200 to more intelligently explain to the external client specific warnings regarding 
the information that the external client is attempting to access. For example, the 
processing of the method 200 may generate a WWW browser page or dialogue box 

1 5 that instructs the external client on how to access the information in a secure fashion 
from a different reference link that is preferred or warns the external client that if it 
proceeds the access attempt will be logged and reported to a security administrator. 

The embodiments of FIG. 2 demonstrate how a secure session with a secure 
site is more intelligently managed, such that warnings are not continually displayed 

20 when not needed and such that only true security risks are identified and dealt with 
in more understandable manners to the external client. In this way, the 
embodiments of this invention improve the usability and management of a secure 
session and increase a secure session's efficiency and meaningfulness from the 
perspective of an external client that participates in the secure session. 

25 FIG. 3 is a diagram of a secure communications management system 300. 

The secure communications management system 300 is implemented in a computer 
readable and accessible medium. Furthermore, the secure communications 
management system 300 is interjected into the processing logic associated with a 
secure session that occurs between a secure site and an external client 320 over a 

30 network 310. 
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The secure communications management system 300 includes a secure 
communications manager 301 and a proxy 302. The secure communications 
manager 301 manages a secure session with the external client 320. The external 
client 320 is associated with an insecure site and communicates with the secure 
5 communications manager 301 over a network 310 using secure communications 
{e.g., HTTPS). 

The secure communications management system 300 uses techniques for 
translating non secure communications into secure communications, such as by 
using a Secure Excelerator product that is provided by Novell, Inc. of Provo, Utah. 

10 This permits secure communications issued from the external client 320 to be 

converted into non-secure communications within the secure site and the results to 
be converted back into secure communications and presented to the external client 
320. These techniques and there embodiments can be found in U.S. Patent Numbers 
6,640,302 and 6,081,900 both commonly assigned to Novell, Inc. of Provo, Utah, 

15 both entitled: "Secure Intranet Access." The disclosures of these patents are 

incorporated by reference herein. These techniques can be used by both the secure 
communications manager 301 and the proxy 302 of the secure communications 
manager system 300. 

During the secure session, the external client 320 makes access attempts 

20 directed towards resources, information, services, or sites. These access attempts 
are typically embedded as link references within other information that the external 
client 320 is attempting to view within the secure session. For example, the external 
client may access a WWW page on the secure site during the secure session which 
includes embedded links to other resources, information, services, or sites. Before 

25 the WWW page is presented to the external client 320 for viewing and accessing, 
the secure communications manager 301 scans it for embedded references directed 
towards potentially insecure references. 

A potentially insecure reference is one that is referenced by a non-secure 
communications protocol (e.g., HTTP) or one that is not contained within the secure 

30 site or under the direct control of the secure communications manager system 300. 
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When potentially insecure references are identified, they are inspected by the 
secure communications manager 301 to determine how, if at all, they should be 
processed or dealt with before they are presented to the external client 320, if at all. 
Thus, in some instances, the potentially insecure references are translated into 
5 secure references by the proxy 302 and made available to the external client 320 
over the network 310. In other instances, the proxy 302 acts as an intermediary for 
the external client 320 and translates insecure references to secure references and 
vice versa, such that the external client believes that the transactions are occurring 
within the secure session. In still other embodiments, the secure communications 

10 manager 301 determines that the potentially insecure references are too risky and 
removes them entirely from any WWW page that is presented to the external client 
320. In these latter embodiments, the secure communications manager 301 or the 
proxy 302 may generate custom warning messages that they present to the external 
client 320 during the secure session, may notify external security entities of the 

15 access attempts, or may record the access attempts to a security log for later 
evaluation or use. 

Thus, the proxy 302 selectively processes the potentially insecure references 
on behalf of the external client 320 within the secure session. Any normally 
occurring security messages that are not needed are suppressed in the external 

20 client's WWW browser and custom warning messages can be generated to produce 
better explanations of security risks and actions as needed. Moreover, the external 
client 320 can process potentially insecure references safely via the proxy 302 
during the secure session. 

The embodiments of the secure communications manager system 300 

25 permits better management of secure communications occurring between an 

external client and a secure site. This is achieved by translating between secure and 
non-secure communications, inspecting potentially insecure references in advance 
of providing them to the external client 320, and taking action on the potentially 
insecure references based on the true nature of those references in advance of 

30 providing them to the external client 320. 
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FIG. 4 is a diagram of another secure communications management system 
400. The secure communications management system 400 is implemented in a 
computer readable and accessible medium. Furthermore, the secure 
communications management system 400 is implemented within a secure site that is 
5 accessible to an external client 410 associated with an insecure site. The external 
client 410 communicates with the secure site via a secure communications protocol, 
such as HTTPS. The external client 410 authenticates itself to the secure site in 
order to initiate the secure communications and begin a secure session with the 
secure site. 

10 The secure communications management system 400 includes a secure 

session 401, secure reference links 402, potentially insecure reference links 403, and 
optionally a proxy 404. The reference links 401-402 are identifiers for or addresses 
to resources, information, services, or sites that the external client 410 can access 
during the secure session 401. The resources, information, services, or sites may 

1 5 physically reside within the secure site or may physically reside on sites external to 
the secure site. 

As previously mentioned, the secure session 401 is initially created when the 
external client 420 logs into the secure site or otherwise authenticates {e.g., via the 
proxy 404) to the secure site. Once this is done, the external client 420 and the 

20 secure site and its resources communicate with one another via secure 

communications (e.g., HTTPS). A secure session can terminate normally {e.g., 
explicit log out request), terminate after a time-out {e.g., a configurable period of 
time during which no activity is detected by the external client 420), or terminate 
abnormally {e.g., when a program, service, communication line fails). 

25 During operation of the secure communications management system 400, 

the external client 420 accesses WWW pages, files, or other information that 
includes secure reference links 402 and potentially insecure reference links 403. 
Before these pages, files, or other information are rendered to the external client 410 
for accessing and viewing, they are scanned to identify the potentially insecure 

30 reference links 403. The potentially insecure reference links 403 can be identified 
by references to a non-secure communications protocol {e.g., HTTP) or when 
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references are identified as being part of a pre-defined list of acceptable or 
unacceptable references or when references are not recognized as being known to 
the secure site. 

Once any potentially insecure reference links 403 are identified, actions can 
5 be performed on the potentially insecure reference links 403 before vending 
information that contains those potentially insecure reference links 403 to the 
external client 410. 

One modification is to replace a number of the potentially insecure reference 
links 403 with secure communication protocols (e.g., HTTPS). This is useful when 

10 the potentially insecure references 403 are associated with resources, information, 
services, or sites that are wholly contained and controlled within the secure site. 
This may also be useful when the potentially insecure references 403 are associated 
with trusted resources, information, services, or sites to the secure site. In some 
embodiments, the modifications are dynamically performed within the proxy 404 

15 during the secure session, such that the external client 410 is unaware of the 

translations occurring between secure and insecure communications and believes 
that all access is occurring normally during the secure session. 

Another modification is to remove a number of the potentially insecure 
reference links 403 entirely from any information that is vended to the external 

20 client 410. This may be useful, when the removed references are known to be 

insecure or determined to have been tampered with in some way. For example, the 
metadata or header associated with a removed reference link may include a cookie. 
Alternatively, the removed reference may be a known site that is problematic to an 
enterprise. When a reference link is removed this event can be reported to a security 

25 entity, written to a log, associated with a custom warning message inserted into the 
vended information, or included with no additional information within the vended 
information, such that the external client 410 is entirely unaware that the reference 
link was removed from the vended information. 

In some embodiments, it may be determined that normally occurring 

30 security messages that an external client's 410 WWW browser would normally 
issue in view of the potentially insecure references 403 should be issued. In these 
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instances, the processing of the secure communications management system 400 
can elect to take no action on the potentially insecure references 403. 

The secure communications management system 400 permits secure 
communications occurring between a secure site and external client 410 to occur in 
5 more meaningful and less intrusive manners. This occurs because invalid or 

unneeded security warnings are suppressed, selective non secure communications 
can occur via proxy 404 in a secure fashion with the external client 410, and more 
meaningful actions or warnings can be custom developed and presented to the 
external client 410 for action when true security concerns arise during the security 
10 session. 

Although specific embodiments have been illustrated and described herein, 
one of ordinary skill in the art will appreciate that any arrangement calculated to 
achieve the same purpose can be substituted for the specific embodiments shown. 
This disclosure is intended to cover all adaptations or variations of various 

15 embodiments of the invention. It is to be understood that the above description has 
been made in an illustrative fashion only. Combinations of the above embodiments, 
and other embodiments not specifically described herein will be apparent to one of 
ordinary skill in the art upon reviewing the above description. The scope of various 
embodiments of the invention includes any other applications in which the above 

20 structures and methods are used. Therefore, the scope of various embodiments of 
the invention should be determined with reference to the appended claims, along 
with the full range of equivalents to which such claims are entitled. 

It is emphasized that the Abstract is provided to comply with 37 C.F.R. 
§ 1.72(b), which requires an Abstract that will allow the reader to quickly ascertain 

25 the nature and gist of the technical disclosure. It is submitted with the 

understanding that it will not be used to interpret or limit the scope or meaning of 
the claims. 

In the foregoing Detailed Description, various features are grouped together 
in single embodiments for the purpose of description. This method of disclosure is 
30 not to be interpreted as reflecting an intention that the claimed embodiments of the 
invention require more features than are expressly recited in each claim. Rather, as 
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the following claims reflect, inventive subject matter lies in less than all features of 
a single disclosed embodiment. The following claims are hereby incorporated into 
the Detailed Description, with each claim standing on its own as a separate preferred 
embodiment. 
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